Wicked Evolutions
Layer 02 · Protocol · WordPress Plugin

The portal is open.
The map of the territory.
Every ability. WordPress is AI Native.

The gate. The portal. The layer that translates the entire WordPress Abilities API into the Model Context Protocol. Without it, nothing connects. With it, every registered ability on your site becomes an MCP tool — reachable by any AI client, permission-gated, schema-validated.

MCP Adapter / 01 — In one breath

What it is. Why it exists. How it works. What it brings you.

A plain reading of this plugin before the technical detail. Same shape as every product in the Trinity — value first, spec second.

What
A WordPress plugin that opens an AI-callable surface on your site.
It speaks the Model Context Protocol over HTTPS. Anything registered as a WordPress Ability becomes an MCP tool the moment this plugin is active.
Why
So an AI can reach your site without you pasting a password.
No bot user. No long-lived admin token glued into a config file. OAuth 2.1, scoped keys, a consent screen the operator actually sees.
How
It validates schema, checks the cap, redacts the response, and returns.
Every call passes through the same gate. Capability check → input validation → ability runs → output redaction → response. Same path. Every time. No exceptions.
What it brings
Trust you can audit, not trust you have to take on faith.
You see what the AI was allowed to do. You see what was denied, and why. You see what was sent back — and what was scrubbed before it left the site.
MCP Adapter / 02 — Discovery

How a WordPress ability becomes an MCP tool.

Four steps, and they all happen inside your site. Nothing leaves. Nothing has to be re-declared in a separate manifest. The Adapter reads the WordPress Abilities API and turns each ability into a tool description an AI can read.

Step 01
Read the registry
The Adapter asks WordPress for every ability that's been registered — by core, by Abilities for AI, by Fluent, by any plugin you've installed.
in-process · no network
Step 02
Translate
Each ability's name, description, input schema and permissions become an MCP tool description. The AI now knows what's available — and what each thing requires.
schema preserved 1:1
Step 03
Annotate
Read-only? Destructive? Idempotent? The Adapter labels every tool with the same hints WordPress already declared — so the AI can plan before it acts.
honest by default
Step 04
Expose
The translated catalogue is what the AI client sees. The AI never sees raw WordPress internals — only the abilities your site chose to register.
surface = registry
MCP Adapter / 03 — The gate

Every call. Every time. No exceptions.

There is one path through the Adapter and everything takes it. You can audit it because there's only one to audit. The same gate runs whether the call is "list posts" or "delete a user."

What it does
Authentication.
OAuth 2.1 with scoped keys. No pasted passwords. No bot users. No long-lived admin tokens.
The first time a client connects, you see a consent screen and pick the scope — read-only, editor, admin. The key it gets is bound to that scope and to that client. You can revoke it from inside WordPress without uninstalling anything.
What it brings
Three-bucket redaction.
Secrets are stripped. Payment data is stripped. Contact PII is stripped — unless the call's scope explicitly opens that bucket.
The Adapter knows three categories of content that should never leave the site by accident. Each call's scope decides which buckets are open and which are sealed. The default is sealed.
MCP Adapter / 04 — Permissions

Delete is off. You turn it on.

A working principle, not a feature. Every destructive ability ships off. Read-everything is the start. Write-things is a deliberate scope you grant. Delete-things is a separate one. The Adapter never assumes.

Default
Delete is off.
Out of the box, an AI client connected via the Adapter cannot delete a post, a user, a file, a row in any table — nor any ability annotated as destructive. Even with admin scope, the destructive group is a separate switch.
Operator-enabled
You turn it on.
Inside WordPress, you flip the destructive scope on for the clients you trust. The flip is auditable, reversible, and per-client. The AI doesn't ask once and gain delete forever — the flip is yours, the audit is yours.
MCP Adapter / 05 — Annotations

The AI knows what's safe before it calls.

An annotation is a label on a tool that tells the AI what kind of action this is. It comes from the Abilities API, the Adapter just passes it through honestly. The result: an AI that can plan a sequence without learning by breaking things.

Annotation
Read-only
"This call returns information and changes nothing." Safe to chain, safe to retry, safe to compose. The AI can fan these out to compile context.
Annotation
Idempotent write
"This call changes state but the same input produces the same result." Safe to retry on a network blip without doubling the effect.
Annotation
Destructive
"This call removes or overwrites." The AI is taught to confirm. The Adapter is set to deny by default. Two locks, not one.
MCP Adapter / 06 — How it relates

The Adapter is one of three. All three are needed.

The Adapter is the gate on each WordPress site. Abilities MCP is the bridge that knocks. Abilities for AI is what's behind the door, ready to be called. None of the three works alone.

← Layer 01
Abilities MCP
The bridge that runs on your machine and routes the call to the right site.
This page
MCP Adapter
The gate on each site that authenticates, validates, redacts, and returns.
Layer 03 →
Abilities for AI
Every WordPress surface, registered as a callable named operation behind the gate.